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Mobile IPv6 Experimental Messages 
Status of This Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 

Official Protocol Standards" (STD 1) for the standardization state 

and status of this protocol. Distribution of this memo is unlimited. 
Abstract 


This document defines a new experimental Mobility Header message and 
a Mobility option that can be used for experimental extensions to the 
Mobile IPv6 protocol. 
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1. Introduction 


When experimenting with a protocol or defining a new extension to a 
protocol, one needs either a protocol number, a new message, or an 
option to carry the information related to the experiment. Most 
implementations end up using unassigned values for the new messages. 
Many times this creates problems when the same value is assigned 
through the IETF standards action, by IANA, or if the implementation 


gets deployed with these messages. Therefore, it is considered a 
good practice to set aside some code points that identify the 
experimental protocols or messages for experimental purposes. The 


need for experimental messages is shown in [3]. 
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This document defines new messages for experimenting with extensions 
to the Mobile IPv6 protocol. These messages should be strictly used 
for experiments. Experiments that are successful should be 
standardized in the IETF. An implementation MUST NOT be released or 
deployed with the experimental messages. 


This document defines a new Mobility Header message, which is the 
Experimental Mobility message that can be sent at any time by the 
mobile node, the home agent or the correspondent node. Since 
Mobility Header messages cannot be combined and sent in one packet, 
there is always only one Mobility Header message in any Mobile IPv6 
packet. Home agent or correspondent node implementations that do not 
recognize the mobility message type, discard the message and send a 
Binding Error message as described in [2], with the Status field set 
to 2 (unrecognized MH Type value). Mobile nodes that do not 
recognize the mobility message type should discard the message and 
send an ICMP Parameter problem with code 0. 


This document also defines a new mobility option, the Experimental 
Mobility option, which can be carried in any Mobility Header message. 
Mobility options, by definition, can be skipped if an implementation 
does not recognize the mobility option type [2]. 


The messages defined in this document can also be used for Network 
Mobility (NEMO) [4] and Proxy Mobile IPv6 [5] since these protocols 
also use Mobility Header messages. 


Experimental code points could potentially disrupt a deployed network 
when experiments using these code points are performed in the 
network. Therefore, the network scope of support for experimental 
values should carefully be evaluated before deploying any experiment 
across extended network domains, such as the public Internet. 


Experimental mechanisms should only be used for actual 
experimentation. By design, only a single code point is allocated 
for the message and another one for the option. This limits the 
number of experiments among a set of peers to one at a time. When 
experimental mechanisms are shown to be useful, and there is a desire 
to deploy them beyond the experiment they should be standardized and 
given new code points. 


2. Terminology 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 


"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [1]. 
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3. Experimental Mobility Header Message 


The Experimental Mobility Header message is based on the Mobility 
Header message defined in Section 6.1 of RFC 3775 [2]. There are no 
fields in the message beyond the required fields in the Mobility 
Header. The 'MH Type' field in the Mobility Header indicates that it 
is an Experimental Mobility Header message. 


If no data is present in the message, two bytes of padding are 
required. The 'Header Len' field in the Mobility Header is set to 0 
since the first 8 octets are excluded while calculating the length of 
the Mobility Header message. 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


| Payload Proto | Header Len | MH Type Reserved 
+ -4+-4+-4+-4+-4+-4+-4+-4+-4+-+-4+-4+->4+>4+->4+-4+->4+-4+-4+->4+-4+-4+-4+-4+-4+-4+->4+-+->4+-4+-+-+ 
| Checksum | | 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Message Data 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


See RFC 3775 [2] for a description of the 'Payload Proto’, 'Header 
Len’, 'MH Type’, 'Reserved', and 'Checksum' fields. 


The 'Message Data' field carries the data specific to the 
experimental protocol extension. The total length of the message is 
indicated by the 'Header Len' field in the Mobility Header. 


4. Experimental Mobility Option 


The Experimental Mobility option can be included in any Mobility 
Header message. If the Mobility Header message includes a Binding 
Authorization Data option [2], then the Experimental Mobility option 
should appear before the Binding Authorization Data option. 


0 1 2 3 

0: 172-345 6 778.9 O 27374/75-767788. 970172. 3.4 5 6.7.8 9 04 
+->4+-+-+-+-+-+->+-+-+-+-+->+-+-+-+-+->+-+-+-+-+->+-+-+-+-+->+>+->+-+-+=>+ 
| Type | Length | Data bacs 
+->4+-+-+-+-+-+-+-+-+-+-+->+-+-+-+-+->+-+-+-+->+-+->+-+-+-+->+->+-+-+-+=>+ 
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Type 


An 8-bit field indicating that it is an experimental mobility 
option. 


Length 


An 8-bit field indicating the length of the option in octets 
excluding the Type and Length fields. 


Data 
Data related to the experimental protocol extension. 
5. Security Considerations 


Protection for the Experimental Mobility Header message and Mobility 
option depends on the experiment that is being carried out and the 
kind of information that is being carried in the messages. If these 
messages carry information that should not be revealed on the wire, 
or that can affect the binding cache entry at the home agent or the 
correspondent node, they should be protected in a manner similar to 
Binding Updates and Binding Acknowledgements. 


Security analyzers such as firewalls and network intrusion detection 
monitors often rely on unambiguous interpretations of the fields 
described in this document. As new values for the fields are 
assigned, existing security analyzers that do not understand the new 
values may fail, resulting in either loss of connectivity, if the 
analyzer declines to forward the unrecognized traffic, or in loss of 
security if it does forward the traffic and the new values are used 
as part of an attack. 


When experimental code points are deployed within an administratively 
self-contained network domain, it must be ensured that each code 
point is used consistently to avoid interference between experiments. 
When experimental code points are used in traffic that crosses 
multiple administrative domains, the experimenters should assume that 
there is a risk that the same code points will be used simultaneously 
by other experiments and that there is a possibility that the 
experiments will interfere. Particular attention should be given to 
security threats that such interference might create. Please see RFC 
4727 for more details [6]. 
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6. IANA Considerations 


The Experimental Mobility Header message, defined in Section 3, has 
been assigned the type value (11), allocated from the same space as 
the 'MH Type' field in the Mobility Header [2]. 


The Experimental Mobility option, defined in Section 4, has been 
assigned the type value (18), allocated from the same space as 
Mobility Options [2]. 
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